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"It's raining cats and dogs!" 
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Type Enforcement 

The SELinux primary model or enforcement is called type enforcement. 
Basically this means we define the label on a process based on its type, 
and the label on a file system object based on its type. 

Imagine a system where we define types on objects like cats and dogs. 
A cat and dog are process types. 
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We have a class of objects that they want to interact with which we call 
food. And I want to add types to the food, cat_chow and dog_chow. 

CAT-CHOW DOfr^GHoW 




As a policy writer, I would say that a dog has permission to eat dog_chow 
write this rule in policy, as shown below. 
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food and a cat has permission to eat cat_chow food. In SELinux we would 




POfr-CHoWFOOD 



EAT 



With these rules the kernel would allow the cat process to eat food labeled 
cat_chow and the dog to eat food labeled dog_chow. 




po^-CHoW-.foop 



But in an SELinux system everything is denied by default. This means that if 
the dog process tried to eat the cat_chow, the kernel would prevent it. 



kernel 




Likewise cats would not be allowed to touch dog food. 

No! bad cat! kernel 
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MCS Enforcement 



We've typed the dog process and cat process, but what happens if you have 
multiple dogs processes: Fido and Spot. You want to stop Fido from eating 
Spot's dog_chow. 

SPOT 




One solution would be to create lots of new types, like Fido dog and 

Fido_dog_chow. But, this will quickly become unruly because all dogs 
have pretty much the same permissions. 

To handle this we developed a new form of enforcement, which we call 
Multi Category Security (MCS). In MCS, we add another section of the label 
which we can apply to the dog process and to the dog_chow food. Now we 
label the dog process as dog:random1 (Fido) and dog:random2 (Spot). 



We label the dog chow as dog_chow:random1 (Fido) and 
dog_chow:random2 (Spot). 
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MCS rules say that if the type enforcement rules are OK and the random MCS labels 
match exactly, then the access is allowed, if not it is denied. 




Fido (dog:random1) is allowed to eat dog_chow:random1. 
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Fido (dog:random1) denied to eat spot's (dog_chow:random2) food. 
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MLS Enforcement 



Another form of SELinux enforcement, used much less frequently, is called 
Multi Level Security (MLS); it was developed back in the 60s and is used 
mainly in trusted operating systems like Trusted Solaris. 

The main idea is to control processes based on the level of the data they 
will be using. A secret process can not read top secret data. 

Instead of talking about different dogs, we now look at different breeds. 
We might have a Greyhound and a Chihuahua. 




6rREYH0UNP CHlHuAHuA 

We might want to allow the Greyhound to eat any dog food, but a Chihuahua 
could choke if it tried to eat Greyhound dog food.. 



We want to label the Greyhound as dog:Greyhound and his dog food as 
dog_chow:Greyhound, and label the Chihuahua as dog:Chihuahua and his 
food as dog_chow:Chihuahua. 
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With the MLS policy, we would have the MLS Greyhound label dominate the 
Chihuahua label. This means dog:Greyhound is allowed to eat 
dog_chow:Greyhound and dog_chow:Chihuahua. 




But dog:Chihuahua is not allowed to eat dog_chow:Greyhound. 
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Of course, dog:Greyhound and dog:Chihuahua are still prevented from 
eating cat_chow:Siamese by type enforcement, even if the MLS type 
Greyhound dominates Siamese. 
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